feat: add --timeout flag to override the startup readiness deadline#358
Merged
gtsiolis merged 3 commits intoJul 23, 2026
Merged
Conversation
gtsiolis
added
semver: patch
docs: needed
gtsiolis
force-pushed
the
pro-357-lstk-start-should-time-out-on-failed-startup-0511
branch
4 times, most recently
from
July 9, 2026 07:13
85218c6 to
6b23b5a
Compare
gtsiolis
force-pushed
the
pro-357-lstk-start-should-time-out-on-failed-startup-0511
branch
2 times, most recently
from
July 16, 2026 07:09
f00d3ea to
dd4f388
Compare
lstk start (and the bare root) now accept --timeout <duration> to bound how long lstk waits for the emulator to report healthy. When set explicitly it overrides LSTK_STARTUP_TIMEOUT for a single run; --timeout 0 falls back to the per-mode default. restart and the snapshot auto-start path deliberately do not expose the flag. The underlying startup-timeout mechanism — per-mode defaults, the interactive keep-waiting/stop prompt, and startupMonitor — landed separately in #390; this change only exposes it as a CLI flag and adds an integration test covering the non-interactive timeout path. Generated with [Linear](https://linear.app/localstack/issue/PRO-357/lstk-start-should-time-out-on-failed-startup#agent-session-92655d31) Co-authored-by: linear-code[bot] <222613912+linear-code[bot]@users.noreply.github.com> Co-Authored-By: Claude <noreply@anthropic.com>
gtsiolis
force-pushed
the
pro-357-lstk-start-should-time-out-on-failed-startup-0511
branch
from
July 23, 2026 09:07
dd4f388 to
018812c
Compare
gtsiolis
changed the title
gtsiolis
marked this pull request as ready for review
July 23, 2026 09:13
… wait Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
skyrpex
approved these changes
Jul 23, 2026
skyrpex
left a comment
skyrpex
left a comment
Contributor
There was a problem hiding this comment.
Not much to say, it looks good to me and the functionality is very welcomed.
gtsiolis
deleted the
pro-357-lstk-start-should-time-out-on-failed-startup-0511
branch
July 23, 2026 11:02
Contributor
|
BTW love the difference in behavior between interactive and non-interactive. Interactive: Non-interactive: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
lstk startcould wait indefinitely when the emulator never became healthy, hanging CI and other non-interactive jobs until an external timeout killed them (reported by harsh.mishra). The startup wait itself was later bounded in #390 (per-mode defaults +LSTK_STARTUP_TIMEOUT); this PR adds the command-line--timeoutflag PRO-357 asked for, so the deadline is controllable per run without an env var.Changes
--timeout <duration>flag tostart(and the bare root, which starts the emulator when invoked with no subcommand).cfg.StartupTimeoutfor that run (applyTimeoutFlagincmd/root.go). An unset flag preservesLSTK_STARTUP_TIMEOUT, which in turn falls back to the per-mode default inresolveStartupTimeout(20s interactive / 60s non-interactive).--timeout 0uses the per-mode default rather than disabling the timeout — there is intentionally no indefinite wait (that was the hang Fixlstk startwaits forever when the container fails during startup #390 fixed). This differs from the flag behavior originally suggested on the ticket (5mdefault,0disables), which predates Fixlstk startwaits forever when the container fails during startup #390's mechanism.restartand the snapshot auto-start path deliberately do not expose the flag; they keep using the env/config value.LSTK_STARTUP_TIMEOUTentry inCLAUDE.md.Scope note: the timeout mechanism itself —
startupMonitor, per-mode defaults, the interactive keep-waiting/stop prompt,startupTimeoutError, and thestart_timeouttelemetry code — landed in #390. After rebasing ontomainthis PR is scoped to exposing that mechanism as a CLI flag plus a non-interactive integration test.Review
Human review advised — adds new user-facing behavior (a
--timeoutflag), which the review-scope checklist routes to human review regardless of diff size.Tests
TestStartTimesOutWhenEmulatorNeverBecomesHealthy: starts a local image that stays running but never serves/_localstack/health, runsstart --timeout 3snon-interactively, and asserts the fast failure (clear error + exit 1).TestStartupMonitorAwait_*,TestResolveStartupTimeout,TestStartContainers_TimeoutEmitsErrorAndTelemetry) is retained from Fixlstk startwaits forever when the container fails during startup #390.go build ./...;lstk start --helpandlstk --helpboth list--timeout; an invalid value (--timeout bogus) is rejected with a usage error.Closes PRO-357